home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 92 < prev    next >
Encoding:
Text File  |  1996-08-05  |  5.8 KB  |  108 lines
  1. Path: ac.dal.ca!cook
  2. Newsgroups: comp.lang.c++
  3. Subject: Re: Let's save Borland C++ and OWL
  4. Message-ID: <1996Jan1.123321.44509@ac.dal.ca>
  5. From: cook@is.dal.ca (Adrian Ross Cook)
  6. Date: 1 Jan 96 12:33:20 -0400
  7. References: <4bmnv0$l9i@serv.hinet.net>
  8. Nntp-Posting-Host: is.dal.ca
  9. X-Newsreader: TIN [version 1.2 PL2]
  10.  
  11. I whole-heartedly agree with what you've said. The quality of Borland 
  12. documentation is really awful. I've had more than one similar experience 
  13. using Turbo C++ for Windows. My favourite memory is of trying to figure 
  14. out what STRICT was all about and how it should be used. Borland led me 
  15. on a wild goose chase through all the documentation I had. I still 
  16. haven't got it to work properly.
  17.  
  18. It's really too bad, because the OWL library does seem really 
  19. well-designed and Borland compilers seem fine in all aspects but their 
  20. documentation.
  21.  
  22. Adrian Cook
  23. cook@is.dal.ca
  24.  
  25. Lyndon Lin (ll7755@c2.hinet.net) wrote:
  26. : After thorough experiences with both VC++ and BC++, I believe that BC++ 
  27. : and it's OWL framework library is worth of living in the market. But 
  28. : Borland's documentation is too much worse in compared with Microsoft's. 
  29. : This hurts a lot for public acceptance of them. I'm now collecting all my 
  30. : witness about the error, incompleteness, confusing of their documents.
  31.  
  32. :   Let me give you one of them.
  33.  
  34. :   Do you know how to trace into OWL's source code? 
  35. :   I was driven to mad in searching for the procedure. After reading 
  36. : through all the relevant documentation (Turbo Debugger User Guide, BC++ 
  37. : User Guide, Borland Tech. Info in Borland's Web site, ReadMe files), I 
  38. : was still out of luck. I just found that BC++ installation program didn't 
  39. : copy the necessary diagnostic version of DLL and import library(I choosed 
  40. : to have a FULL installation). So I copy it by hand. It help nothing. It 
  41. : seems to be resonable since in C++ termilogy, diagnostic means exception 
  42. : handling and Run Time Type Identification (RTTI), it is nothing to do 
  43. : with symbolic debugging. Then I reviewed the supplied make file for OWL 
  44. : library source. (I's was never a make file lover.) It's evident that 
  45. : you can build a debug version of the OWL by defining a directive. But 
  46. : it is also evident that all of BC++'s runtime library should follow 
  47. : some naming convention. For example, the BC++ 4.50 dictates the 16-bit 
  48. : DLL version of OWL library be named OWL250.DLL for distribution and 
  49. : OWL250D.DLL for diagnostics version. But what is the name of a debug 
  50. : version? Nothing was said about it. It seemed to me Borland doesn't 
  51. : giave a position for debug version library. 
  52.  
  53. :   But in the make file, it mentions a directive to stripe off the debug 
  54. : infomation from a debug version EXE or LIB/DLL. In the stripping process, 
  55. : you can opt to create a .TDS file to hold the debug infomation. It 
  56. : doesn't explained further about what is the .TDS file for. Then I recall 
  57. : that in the Turbo Debugger (but not the integrated debugger), when you 
  58. : tried to load another symbol file, it prompt you to supply file with .TDS 
  59. : extention. So I searched again in the CD and found the OWL250.TDS. Sound 
  60. : interesting. I copy it into BC++ BIN directory. Try again. TDW still 
  61. : prompt me to supply a .TDS file (Shouldn't it be able to find the TDS 
  62. : file in the BIN directory?). OK, I pick up the file with the file browser 
  63. : dialog. No luck. TDW sielently accept the TDS, but I still can't trace 
  64. : into OWL source. Maybe I should stick with VC++ anyway. 
  65.  
  66. :   Two days later, I accumulated some more momentum for this mess. Let's 
  67. : try again. In a very occation, I check out the "Diagnostic" check button 
  68. : in the Target Expert dialog to compile my project with diagnostic 
  69. : information. You guess what. When I start up TDW, it bring me to the 
  70. : first assembly instruction in the good old WinMain() function. I got it! 
  71. : In a OWL application, WinMain() exists in the OWL library, not in user 
  72. : code. It means TDW has automatically loaded the OWL library symbol 
  73. : infomation and correctly pinpoint the first line of code to be executed.
  74.  
  75. :   But what about integerated debugger? We usually debug with it for being 
  76. : able to access to other programs and most importantly, all the necessay 
  77. : on-line library reference. It didn't behave as good as TDW, but improve a 
  78. : lot. Immediately at starting up, it prompted you for the Directory to 
  79. : locate a "Applicat.cpp" file. This is the source file for the 
  80. : TApplication class. So the IDE debugger knows what file contains the 
  81. : library source code, it just doesn't know where it is put. After choose 
  82. : the correct directory using the file browser dialog, IDE debugger behaved 
  83. : as good as TDW. Then I try to set some directory information in the 
  84. : project option dialog. The IDE is also able to locate all the necessary 
  85. : source module automatically. This directory setting is documented in the 
  86. : IDE User Guide, but it's not likely that you would think this setting 
  87. : also apply to library source.
  88.  
  89.  
  90. :   You may challenge me why not just call Borland tech support. First, I 
  91. : live in Taiwan, and register with Borland Taiwan. I can't call 
  92. : U.S.A directly for tech support. As for Borland Taiwan, I doubt they have 
  93. : the necessary task force for helping with serious tech. problem regarding 
  94. : C++.
  95. :   
  96. :   Second, this is only one of several hundred of potential problems we 
  97. : are doomed to encounted with, all just because Borland's incapable of 
  98. : suppling the useful documentation we deserve. If Borland doesn't see this 
  99. : as a serious problem, you and me will be forced to switch to Microsoft, 
  100. : and finally the death of an execellent compiler and framework library. 
  101. : It's really a shame to waste you American's telent and effort this way.
  102.  
  103. :   I really wish this posting will arouse all the BC++ user giving more 
  104. : and more of their complaint and witness. Only in that way can we force 
  105. : Borland to improve their documentaion for their next version of software.
  106.  
  107.  
  108.